오픈소스 개발자 대회 협업 규칙

브랜치 전략 (Branch Strategy) 1.1 주요 브랜치 master: 프로덕션(배포)용으로 사용되는 최종 안정 브랜치. 스프린트 종료 시 release에서 병합되며 버전 태그(`v0.0.1`) 부여 release: 프론트 팀 내 QA 및 릴리즈 준비를 위한 브랜치 develop: 기능 개발 완료 후 테스트 및 통합을 위한 브랜치 1.2 보조 브랜치 feature/: 퍼블리싱 화면을 실제 프론트 개발로 전환하는 브랜치 예) `feature/티켓번호`, `feature/티켓번호` publish/: 퍼블리싱 작업을 위한 화면 설계 또는 초기 UI 구성 브랜치 hotfix/: 프로덕션에서 발견된 긴급 버그 수정에 사용 예) `hotfix/issue32`, `hotfix/issue24` 1.3 브랜치 생성 및 병합 흐름 !브랜치 전략 작업 전 `develop` 브랜치에서 새로운 `feature/`, `publish/` 브랜치를 생성 작업 완료 후 PR 작성 및 리뷰어 지정 (nahyeongjin1 → 6keem → hyynjju → nahyeongjin1 순) 리뷰 완료 후 `develop` 브랜치로 머지 긴급 수정 사항은 누구나 `hotfix/` 브랜치를 만들어 수정 후 `develop`과 `master`로 병합 프론트 테스트 완료 시 `develop`에서 `release`로 병합 스프린트 종료 시 `release`를 `master`로 병합하고, 버전을 `v0.0.1` 단위로 태깅 (개발 기간 한정) 커밋 규칙 (Commit Convention) 2.1 Commit message 구조 ``은 커밋 유형을 나타내며 아래 중 하나여야 한다. 2.2 Commit message 규칙 제목 Header 제목과 본문을 빈 행으로 구분한다. 제목은 50글자 이내로 제한 제목의 첫 글자는 대문자로 작성 제목 끝에 마침표 넣지 않기 제목은 명령문으로 사용하며 과거형을 사용하지 않는다 본문 Body 선택 사항 본문의 각 행은 72글자 내로 제한 본문은 어떻게보다 무엇을, 왜에 맞춰 작성하기 바닥글 footer 선택사항 이슈를 추적하기 위한 ID를 추가할 때 사용 `해결` 해결한 이슈 ID `관련` 해당 커밋에 관련된 이슈 ID `참고` 참고할만한 이슈 ID 커밋 예시 Pull Request 규칙 3.1 리뷰어 지정 (Reviewer Assignment) > `nahyeongjin1` → `6keem` → `hyynjju` → `nahyeongjin1` 정해진 순서에 따라 리뷰어 지정 `feature/`, `publish/` 브랜치는 리뷰 완료 후 `develop`으로 머지 `hotfix/`는 긴급 상황에 따라 누구나 생성 및 병합 가능 리뷰어가 제안하는 수정 사항이 있는 경우 PR 제목을 `[WIP]: ` 형식으로 수정하고, 리뷰어는 머지 금지. 작성자는 수정 후 request review 요청 PR을 열기 전에 항상 develop 브랜치 기준으로 rebase 후 force push (레인보우 방지) 3.2 PR 양식 및 머지 방식 PR 제목 형식: `[JIRA TICKET] 티켓 제목` PR 머지 시 반드시 Squash Merge 사용 머지 메시지 형식: `[JIRA TICKET] 티켓 제목 (#PR번호)` 예시 템플릿